It's not clear to me that this shouldn't be public information.

@iaindillingham asked:

Could you help me understand when information should be public and when it shouldn’t,
@seb?

1. You need an account to use it
2. Honeycomb is like an "expert" view. We'd have to explain lots of things for anyone to make use of it. Even if it were free, we're not in a position to make it useful for most users

In contrast, memory and CPU are fairly simple concepts. I don't think they add any extra noise, and I would personally go with the principle that most things should happen in public. You never know what benefits may accrue from exposing the data.

That said, I'm sure @lucyb had a good reason to suggest it should be for logged in users only in #3998...

That said, I'm sure @lucyb had a good reason to suggest it should be for logged in users only in

I was taking a precautionary approach. I wasn't sure the data should be public, since we're receiving it straight from the secure environments, and so I thought it would be best if it was for logged in users only. This also reduces the pressure to present it in a way that's meaningful to most people.

That said, I can't think of a reason why showing it to more people would actually cause an issue.

Thanks, @lucyb. If I've understood opensafely-core/job-runner#686 correctly, then I don't think there's a significant risk of leaking sensitive information. I also don't think that logged in users would be better at interpreting the metrics than public users; if there's an issue with their interpretation, in other words, then I think the issue would apply to both groups of users.

For these reasons, I'm going to remove the check. Sound good, @sebbacon?

You know - now I've thought about this more, I think we should continue this conversation in a more brainstormy forum, and just without it being public, for the time being.

Sorry for the distraction, but it's been useful!

Before I , @ghickman asked on Slack about request.user.is_authenticated.

This information should be displayed on the Job Detail page to logged in users only.

I took "logged in users" from #3998 at face value: an authenticated user is also an authorized user. However, I think George was going to suggest that an authenticated user may not be an authorized user. Is that correct, George?

I think George was going to suggest that an authenticated user may not be an authorized user.

Yep, that's correct, user.is_authenticated does not imply permissions. This is important for us because we have open registration to support applications, so authenticated is barely a step above unauthenticated (by design) for us.

A better gate here would be to check for a permission in the view and pass that as a boolean out to the template via the context. The run_job permission seems like it would fit well here I think?

Alternatively, if you didn't want to be constrained by a particular permission, there's the all_roles property which you could do a truthy check on. It's a bit clunky but it's a pattern we've used in at least one other area.